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© Realzeit-Steuerungssystem. 



© Um Entwicklungskosten zu sparen, sollte ein 
Realzeit-Steuerungssystem die Moglichkeit bieten, 
durch Wechseln von Software wahrend des Betriebs 
nachgeriistet bzw. umgerustet werden zu konnen. 
Diese Eigenschaft wird dadurch erreicht, dafi jede 
Meldung zur Kommunikation neben einer systemweit 
eindeutigen Bezeichnung der adressierten Software- 
Einheit ein Versionskennzeichen enthalt, das dem 
Betriebssystem die Version der adressierten Softwa- 
re-Einheit angibt. 
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Das Umrusten (Up Grade) bzw. Nachrusten 
(Growth) des Steuerungssystems von Vermittlungs- 
stellen durch Wechseln von Software wahrend des 
Betriebs ist ein Mittel, Entwicklungskosten zu ver- 
mindern und dadurch Wettbewerbsvorteile zu er- 
halten. Auf diese Weise kann der Netzbetreiber 
neue Leistungsmerkmale mit verringerter Logistik 
schnell und ohne Betriebsunterbrechung in das 
Netz einbringen. 

Der Erfindung liegt die Aufgabe zugrunde, ein 
bezuglich des Auswechselns von Software flexibles 
Steuerungssystem sowie ein Verfahren zum Aus- 
wechseln von Software in einem Steuerungssystem 
wahrend des Betriebs, d. h. ohne Betriebsunterbre- 
chung anzugeben. 

Diese Aufgabe wird durch die Merkmate des 
Anspruchs 1 und des Anspruchs 2 gelost. 

Eine weitere Ausgestaltung der Erfindung ist 
durch Anspruch 3 gegeben. Durch diese Ausge- 
staltung ist der Kommunikationsaufwand in der Um- 
schaltephase des Kommunikationsverkehrs auf die 
neue geladene Software-Einheit stark verringert, da 
die Mitteilung des neuen Versionskennzeichens nur 
auf die Ereignisquellen beschrankt ist. 

Eine weitere Ausgestaltung der Erfindung ist 
durch Anspruch 5 angegeben. Auf Grund dieser 
Ausgestaltung braucht sich das Betriebssystem 
das fur eine jeweilige Ereignisquelle relevante Ver- 
sionskennzeichen nur wahrend der Umschaltepha- 
se zu merken. 

Eine weitere Ausgestaltung der Erfindung ist 
durch Anspruch 6 gegeben. Durch diese Ausge- 
staltung kann verhindert werden, dafi eine Mel- 
dungs-Kette ausgelost wird, obwohl noch nicht aMe 
fur die genannte Meldungs-Kette zum Austausch 
vorgesehenen Software-Einheiten tatsachlich aus- 
gewechselt, d. h. geladen und aktiviert worden 
sind. 

Eine weitere Ausgestaltung der Erfindung ist 
durch Anspruch 7 angegeben. Durch diese Ausge- 
staltung kann ein Anwender Gruppen von Ereignis- 
sen, sog. Meldungsklassen, zusammenfassen und 
nur diese gemeinsam umschalten. 

Im folgenden wird ein Ausfuhrungsbeispiel der 
Erfindung anhand der Zeichnung naher beschrie- 
ben. 

Figur 1 zeigt ein Schalenmodell fur Verarbei- 
tungsplattformen des erfindungsgemaGen Real- 
zeitsteuerungssystems, 

Figur 2 zeigt den Nachrichtenaustausch zwi- 
schen zwei Dienstleistungsmoduln uber ver- 
schiedene Plattformen, 

Figur 3 veranschaulicht die Kombination des 
Konzepts des Versionskennzeichens mit dem 
Konzept der Ereignisquelle, 
Figur 4 zeigt den NachrichtenfluG durch alte und 
neue Software-Einheiten. 



Figur 1 zeigt ein Schalenmodell fur Verarbei- 
tungsplattformen eines Steuerungssystems, das 
folgende Schalen aufweist: Eine erste Schale, die 
der Hardware der betrachteten drei Verarbeitungs- 

5 plattformen entspricht, 

eine zweite Schale, die der Firmware (Urlader, 
Hardware-Schnittstelle, Fehlererkennung usw.) der 
Verarbeitungsplattform entspricht, 
eine dritte Schale, die der Betriebssystem-Software 

w (Betriebssystemkern, Fehlerbehandlung) entspricht, 
eine vierte Schale, die der Basis-Software (Daten- 
basis, Uberlaststeuerung usw.) der Verarbeitungs- 
plattform entspricht und die mehrere Software-Ein- 
heiten, sogenannte Kapseln, umfaGt, 

is eine funfte Schale, die der System-Software (Konfi- 
gurations-Software mit erfindungsgemaflem Erwei- 
terungsmanager, Recovery-Software usw.) der Ver- 
arbeitungsplattform entspricht und die ebenfalls 
mehrere Kapseln umfaGt, 

20 eine sechste Schale, die der Anwender-Software 
(Vermittlungstechnik, Bedienerschnittstelle, Proto- 
kollabwicklung usw.) der Verarbeitungsplattform 
entspricht und die ebenfalls mehrere Kapseln um- 
faGt. 

25 Nur die oberhalb der zweiten Schale ablaufen- 

de Software wird in Dienstleistungsmodulen SPU 
und in Kapseln zusammengefaBt. Die Schalen 1 bis 
3 stellen zusammen die Grundverarbeitungsplatt- 
form dar und sind fur jeden Verarbeitungsplattform- 

30 typ gleich. 

Ein Dienstleistungsmodul umfaGt eine Menge 
von ProzeG- und Datenmodulen, die eine stark 
funktionale Beziehung zueinander haben und deren 
Inkarnationen (Dienstinstanzen) eine Gruppe von 

35 Diensten fur die ubrige Software Oder die Teilneh- 
mer des Vermittlungssystems zur Verfugung stel- 
len. Die Komponenten (Modulen) eines Dienstlei- 
stungsmoduls befinden sich in demselben Adress- 
raum des Speichers. Deshalb konnen fur die Kom- 

40 munikation innerhalb eines Dienstleistungsmoduls 
lokale Prozeduraufrufe und gemeinsame Speicher- 
mechanismen benutzt werden. 

Eine Kapsel umfaBt eine Gruppe von Dienstlei- 
stungsmodulen, denen gemeinsam ein bestimmtes 

45 Budget von Betriebsmitteln (z.B. geschutzter 
Adressraum, Freispeicher, Zeitgeber) zur Verfu- 
gung gestellt ist. Eine Kapsel kann On-line, d.h. 
ohne Betriebsunterbrechung vom Betriebssystem 
in den Speicher des Steuerungssystems geladen 

so und aktiviert werden. Die Kapsel stellt damit eine 
nach dem erfindungsgemaGen Verfahren aus- 
tauschbare Software-Einheit dar. 

Das Dienstleistungmodui ist eine relozierbare 
Einheit, d.h. es kann von einer Kapsel zu einer 

55 anderen Kapsel und ebenso von einer Verarbei- 
tungsplattform zu einer anderen Verarbeitungsplatt- 
form zur Produktionszeit des Steuerungssystems 
bewegt werden. Daraus ergibt sich, dafi die 
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Schnittstellen eines Dienstleistungsmoduls durch 
Ausdrucke (Primitiven) der Inter-ProzeG-Kommuni- 
kation definiert werden mussen (z.B. CAST, Remo- 
te-Prozeduren). Jede Aktion Oder jeder Steuerungs- 
datenflufi zwischen zwei Dienstleistungsmodulen 
wird durch die Ubergabe von Meldungen ausge- 
Idst. Die Kommunikation zwischen zwei Dienstlei- 
stungsmodulen erfolgt somit ausschlieGlich iiber 
das Betriebssystem. 

Figur 2 zeigt den Nachrichtenaustausch zwi- 
schen zwei Dienstleistungsmodulen uber Plattfor- 
men A, B und C. Jede ubertragene Meldung M 
zwischen verschiedenen Plattformen (Oder inner- 
halb einer Plattform zwischen verschiedenen 
Dienstleistungsmodulen SPU) besitzt einen globa- 
len Nachrichtenkopf (Header). In diesem Nachrich- 
tenkopf ist ein bestimmter Teil fur ein Versions- 
kennzeichen UT (Upgrade Token) reserviert, das 
dem Betriebssystem anzeigt, an welche Version 
einer Software-Einheit die entsprechende Meldung 
gesendet werden soil. 

Immer wenn eine Dienstinstanz eines Dienstlei- 
stungsmoduls eine Kommunikationsbeziehung mit 
einer anderen Dienstinstanz eines anderen Dienst- 
leistungsmoduls zwecks Ausfuhrung eines Dienstes 
herstellen will, so fuhrt sie einen entsprechenden 
Aufruf (Kommunikationsanforderung) an das Be- 
triebssystem durch, in welchem der Name des 
angeforderten Diensttyps sowie weitere Auswahlkri- 
terien angegeben sind, u.a. das bereits genannte 
Versionskennzeichen UT. 

Als Resultat des Aufrufs erhalt die aufrufende 
Dienstinstanz einen sogenannnten Kommunika- 
tionspfad (Kommunikationskanal) zuruck, mit Hilfe 
dessen die Kommunikation zu der ausgewahlten 
Server-Dienstinstanz aufgenommen werden kann. 
Die eigentliche Kommunikation wird sodann durch 
Senden von Meldungen Oder Aufrufen von Remote- 
Prozeduren durchgefuhrt 

Jeder Anreiz (Ereignis), der eine Meldung zwi- 
schen zwei Dienstleistungsmodulen auslost, kann 
eindeutig als auGerer oder innerer Anreiz spezifi- 
ziert werden. Ein aufierer Anreiz ist eine Meldung 
eines dritten Dienstleistungsmoduls, wahrend jeder 
andere Anreiz ein innerer Anreiz (z.B. Hardware- 
Interrupt) ist. Software, die eine Meldung aufgrund 
eines inneren Anreizes aussendet, wird im folgen- 
den als Ereignisquelle (Event Source) bezeichnet. 

Ereignisquellen kommen innerhalb des Steue- 
rungssystems z.B. an den Schnittstellen zwischen 
zwei Systemschichten vor, d.h. an denjenigen Stel- 
len, wo Ereignisse (Events) von der Software einer 
Schicht das erste Mai aufgenommen werden. Eine 
Ereignisquelle ist derjenige Teil der Software eines 
Dienstleistungsmoduls durch den ein Hardware- 
oder Software-Ereignis zum ersten Mai bearbeitet 
wird. 



Ein Ereignis kann z. B. das Abheben eines 
Telefonhdrers durch einen Teilnehmer sein. Die 
das Ereignis beschreibende Meldung wird sodann 
einer Ereignisquelle zugesandt. Bei der Bearbei- 
5 tung des Ereignisses durch die Ereignisquelle ent- 
stehen Folgenachrichten, die mit einem Versions- 
kennzeichen UT versehen werden. Welches Ver- 
sionskennzeichen zu benutzen ist, wird der Ereig- 
nisquelle von einem Erweiterungsmanager LUM 
w mitgeteilt. 

Diese Mitteilung wird durch den Erweiterungs- 
manager innerhalb .einer Software-Einheit fur alle 
Ereignisquellen, die einen bestimmten Ereignistyp 
bearbeitetn einheitlich vorgenommen und in einer 

15 entsprechenden Datenstruktur der Software-Einheit 
abgespeichert. Durch das Versionskennzeichen in 
den Folge-Nachrichten wird festgelegt, ob die sich 
an ein Ereignis dieses Ereignistyps anschlieGenden 
Aktionen bzw. Kommunikationen mit Hilfe der neu- 

20 en Software oder der alten Software durchgefuhrt 
werden sollen. 

Durch die Kombination des Konzepts des Ver- 
sionskennzeichens mit dem Konzept der Ereignis- 
quelle ist es moglich, zwischen zwei Softwarever- 

25 sionen einer Software-Einheit ohne Betriebsunter- 
brechung umzuschalten. Diese Umschaltung kann 
als als Soft cut over bezeichnet werden und wird 
wie folgt durchgefuhrt. 

Alle Ereignisquellen des Steuerungssystems 

30 werden nacheinander, d.h. Software-Einheit fur 
Software-Einheit, umgeschaltet, indem das neue 
Versionskennzeichen der neu eingebrachten Ein- 
heit jeweils in entsprechenden Datenstrukturen der 
umzuschaltenden Software-Einheiten (Ereignisquel- 

35 len) abgespeichert wird (siehe Figur 3). Dadurch 
gelangen Meldungen aufgrund neuer Ereignisse 
nurmehr zu der neu geladenen Software-Einheit. 
Wahrend des Umschaltevorgangs bleiben beide 
Versionen der auszutauschenden Software-Einheit 

40 gleichzeitig aktiv und konnen, falls notwendig, Da- 
ten miteinander austauschen. 

Die Dauer des Umschaltevorganges ist so ge- 
wahlt, daG die alte Software-Einheit nach Abschlufi 
des Umschaltevorganges nicht mehr Meldungen 

45 von anderen Software-Einheiten des Steuerungssy- 
stems erhalt und somit fur den .Rest des Steue- 
rungssystems irrelevant geworden ist. Die alte aus- 
zutauschende Software-Einheit kann dann ohne 
weitere Folgen fur die Funktidnalitat des Steue- 

50 rungssystems deaktiviert und aus dem Arbeitsspei- 
cher entfernt werden. 

Figur 3 veranschaulicht die Kombination des 
Konzepts des Versionskennzeichens mit dem Kon- 
zept der Ereignisquelle. In Figur 3a versorgt ein 

55 Erweiterungsmanager LUM der System software 
(funfte Schale) eine Datenstruktur SUC eines 
Dienstleistungsmoduls SPU mit den aktuellen Ver- 
sionskennzeichen UT. Eine Ereignisquelle EV ent- 
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nimmt aufgrund eines Ereignisses aus der Daten- 
struktur SUC das entsprechende aktuelle Versions- 
kennzeichen UT und tragt es in den Nachrichten- 
kopf der Ursprungs-Nachricht ein ("Setzen UT"). 

Des weiteren zeigt Figur 3b die Weiterreichung 
eines Versionskennzeichens in den Nachrichten- 
kopf einer Folge-Nachricht aufgrund eines externen 
Anreizes. Dabei wird das Versionskennzeichen von 
einer empfangenden Dienstinstanz Dl aus dem 
Nachrichtenkopf der empfangenen Nachricht ent- 
nommen und in den Nachrichtenkopf der Folge- 
Nachricht eingetragen (Weiterreichen UT"). 

Figur 4 zeigt den NachrichtenfluG durch alte 
Software-Einheiten SW-0 und neue Software-Ein- 
heiten SW-N aufgrund verschiedener Ereignisse A, 
B und C. Die Ereignisse A, B und C werden dabei 
von Ereignisquellen EV-A, EV-B und EV-C empfan- 
gen, wobei den Ereignisquellen EV-A und EV-B 
vom Erweiterungsmanager LUM ein altes Versions- 
kennzeichen O mitgeteilt worden ist. wahrend der 
Ereignisquelle EV-C ein neues Versionskennzei- 
chene N mitgeteilt worden ist. Wie aus Figur 4 
unmittelbar ersichtlich, kann eine Kommunikations- 
kette trotz eines neuen Versionskennzeichens N 
dennoch uber eine alte Software-Einheit verlaufen, 
wenn diese alte Software-Einheit nicht durch eine 
neue Software-Einheit ersetzt wird. 

Ein Ereignis, das eine Ursprungs-Nachricht 
auslost, kann aus verschiedenen Ereignissen zu- 
sammengesetzt sein. In einem solchen Fall be- 
stimmt dasjenige Teilereignis, das als letztes ein- 
tritt, das zugeordnete Versionskennzeichen fur die 
Ursprungs-Nachricht. Wird beispielswetse ein Zah- 
ler durch verschiedene Nachrichten hochgezahlt, 
so bestimmt das Versionskennzeichen im Nach- 
richtenkopf derjenigen Ursprungs-Nachricht, die 
den Zahler-UberfluG bestimmt, das Erweiterungs- 
zeichen im Nachrichtenkopf der Folge-Nachrichten. 

Eine Ereignisquelle kann des weiteren wahrend 
des Erweiterungsvorganges gesperrt werden, in- 
dem das zu dem zugehorigen Ereignis gehorige 
Kommando (z.B. MML-Kommando) gesperrt wird. 
Diese Moglichkeit stellt sicher, daG wahrend der 
Software-Auswechslungsphase bestimmte Ereigni- 
stypen nicht behandelt werden mussen. 

Fur manche Anwendungen (z.B. CCS7) ist es 
nutzlich, verschiedene Nachrichten bzw. Kommuni- 
kationsketten zu einer Nachrichtenklasse (z.B. 
maintenance-Klasse, application-Klasse) zusam- 
menzufassen. Diese Nachrichtenklasse kann dann 
separat wahrend einer Umschaltephase auf neue 
Software durch einen Trigger des Erweiterungsma- 
nagers umgeschaltet werden und kann in diesem 
Fall als Umschalteinheit bezeichnet werden. 

Erweist sich die neue Software als fehlerhaft, 
ist es mit dem erfindungsgemaGen Verfahren des 
weiteren moglich, ohne Betriebsunterbrechung, d. 
h. weich auf die alte Software zuruckzufallen. Dies 
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wird dadurch erreicht, daG das Versionskennzei- 
chen in einem solchen Fall wieder auf den alten 
Wert zuruckgesetzt wird. Durch diese Rucksetzung 
des Versionskennzeichens werden die Folgemel- 
5 dungen aller Ereignisquellen wieder die alte Soft- 
ware adressieren und die neue Software lafit sich 
somit anschlieGend unterbrechungsfrei aus dem 
Steuerungssystem entfernen. 

Als umzuschaltende Software-Einheiten wurden 
jo bisher Dienstleistungsmodule dargesteilt. Es ist je- 
doch ebenso moglich, als umzuschaltende Softwa- 
re-Einheiten Kapseln vorzusehen, falls als auszu- 
tauschende Software-Einheiten ebenfalls Kapseln 
verwendet werden. 

75 Das aufgrund der erlauterten Software-Mecha- 

nismen realisierte Verfahren laflt sich abschlieGend 
wie folgt beschreiben: 

In einem ersten Schritt wird eine neue Softwa- 
re-Einheit in den Prozessorspeicher geladen und 

20 aktiviert, wobei unter Aktivierung die Inkarnation 
(Instantiierung) der in der Software-Einheit enthal- 
tenden Software-Module zu verstehen ist. Nach 
diesem Schritt ist die geladene Software-Einheit fur 
das gesamte Software-System im Prinzip adres- 

25 sierbar. Da jedoch alle Meldungen aufgrund des 
alten Versionskennzeichens zunachst nur die alte 
Software-Einheit erreichen, werden die Dienste der 
neuen Software-Einheit zunachst noch nicht in An- 
spruch genommen. 

30 In einem zweiten Schritt erfolgt nunmehr das Um- 
schalten des Kommunikationsverkehrs auf die neue 
Software-Einheit. Das Umschalten des Kommunika- 
tionsverkehrs geschieht, wie bereits erwahnt. da- 
durch, daG ohne Betriebsunterbrechung nach und 

35 nach die Versionskennzeichen aller Ereignisquellen 
im Steuerungssystem so eingestellt werden, daft 
alle Nachrichten nur noch zur neuen Software-Ein- 
heit gelangen. Wahrend des Umschaltevorganges 
sind beide Versionen der zu ersetzenden Software- 

40 Einheit gleichzeitig aktiv. 

In einem dritten Schritt wird die alte Software- 
Einheit von der Speicherverwaltung freigegeben. 
Da die alte Software-Einheit nach einem bestimm- 
ten Zeitraum nicht mehr Nachrichten von anderen 

45 Software-Einheiten des Systems erhalt, wird sie 
nach dieser Zeitspanne fur den Rest des Steue- 
rungssystems bedeutungslos. Sie kann damit ohne 
weitere Folgen fur die Funktionalitat des Steue- 
rungssystems freigegeben bzw. geloscht werden. 

so In einem vierten Schritt werden schliefilich die 
Schritte eins bis drei mit weiteren Software-Einhei- 
ten wiederholt, bis alle gewunschten neuen Softwa- 
reteile in das System eingebracht wurden. 

Eine wesentliche Randbedingung fur das be- 

55 schriebene Verfahren ist die Koexistenz (Kompati- 
bilitat) von neuer zu alter Software, d. h. neu einge- 
brachte Software-Einheiten mussen mit weiterhin 
im System verbfeibenden Software-Einheiten zu- 
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sammenarbeiten kdnnen. Diese Bedingung ist aus 
Rgur 4 anschaulich zu entnehmen. 

Patentanspruche 

1. Realzeit-Steuerungssystem mit 

a) wenigstens einem Steuerungsprozessor, 

b) einem Software-System, das in ein Be- 
triebssystem und in eine Mehrzahl von hier- 
archisch daruber liegenden Software-Einhei- 
ten unterteilt ist, die individuell in den Ar- 
beitsspeicher des Steuerungsprozessors 
ladbar sind und die zur Durchfuhrung ihrer 
Steuerungsaufgaben durch Meldungen (M) 
uber das Betriebssystem miteinander kom- 
munizieren, wobei jede Meldung neben ei- 
ner systemweit eindeutigen Bezeichnung 
der adressierten Software-Einheit ein Ver- 
sionskennzeichen (UT) enthalt, das dem Be- 
triebssystem die Version der adressierten 
Software-Einheit angibt, 

c) einem Erweiterungssmanager (LUM) in- 
nerhalb des Software-Systems, der den 
Software-Einheiten das in einer Meldung zu 
verwendende Versionskennzeichen mitteilt. 

2. Verfahren zum Auswechseln von Software in 
einem Steuerungssystem gemaG Anspruch 1, 
demgemafl 

a) eine Software-Einheit von neuer Version 
zunachst in den Arbeitsspeicher des Steue- 
rungsprozessors geladen und aktiviert wird, 

b) sodann der Kommunikationsverkehr ohne 
Unterbrechung auf die neu geiadene Soft- 
ware-Einheit umgeschaltet wird, indem das 
Versionskennzeichen der neu geladenen 
Software-Einheit den ubrigen Software-Ein- 
heiten des Software-Systems mitgeteilt 
wird, 

c) schlieGlich die alte Software- Einheit de- 
aktiviert und der diesbezugliche Speicher- 
bereich vom Betriebssystem wieder freige- 
geben wird. 

3. Verfahren nach Anspruch 2, 
dadurch gekennzeichnet, dafi 

a) das Versionskennzeichen der neu gela- 
denen Software-Einheit nur speziellen Soft- 
ware-Einheiten mitgeteilt wird, namlich so- 
genannten Ereignisquellen, die Aktionen des 
Steuerungssystems aufgrund etnes Ereig- 
nisses ausldsen, indem sie Ursprungs-Mel- 
dungen an andere Software-Einheiten ab- 
senden, 

b) das Versionskennzeichen fur eine Folge- 
Meldung aus der die Folge-Meldung auslo- 
senden Meldung in die Folge-Meldung 
ubernommen wird. 



4. Verfahren nach Anspruch 3, 
dadurch gekennzeichnet, dafl 

das zu verwendende Versionskennzeichen 
(UT) den Ereignisquellen jeweils pro Kommuni- 
5 kationsanforderung mitgeteilt wird. 

5. Verfahren nach Anspruch 3, 
dadurch gekennzeichnet, dafl 

das zu verwendende Versionskennzeichen den 
jo Ereignisquellen vom Erweiterungsmanager 

(LUM) nur einmalig mitgeteilt und dann von 
den Ereignisquellen selbst bei jeder Komrnuni- 
kationsanforderung dem Betriebssystem ange- 
geben wird. 

75 

6. Verfahren nach Anspruch 5, 
dadurch gekennzeichnet, dafi 

eine Ereignisquelle wahrend der Auswechs- 
lungsphase von Software gesperrt werden 
20 kann. 

7. Verfahren nach einem der Anspruche 3 bis 6, 
dadurch gekennzeichnet, dafl 

das neue Versionskennzeichen nur bestimmten 
25 Gruppen von Ereignisquellen mitgeteilt werden 

kann. 

8. Verfahren nach einem der Anspruche 2 bis 7, 
dadurch gekennzeichnet, da/3 

30 a) nach dem Umschatten auf die neue Soft- 

ware-Einheit uberpruft wird, ob die neue 
Software-Einheit fehlerfrei funktioniert, 
b) bei einer festgestellten Fehlerhaftigkeit 
der neuen Software-Einheit durch erneute 

as Mitteilungen an die ubrigen Software-Einhei- 

ten das zu verwendende Versionskennzei- 
chen wieder auf den alten Werrt gesetzt 
wird und anschlieBend die neue Software- 
Einheit deaktiviert und der diesbezugliche 

40 Speicherbereich vom Betriebssystem wie- 

der freigegeben wird. 
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